home *** CD-ROM | disk | FTP | other *** search
- From: "Kevin O'Donovan" <abaddon@nasoftwr.demon.co.uk>
- Subject: Re: Dialogs!
- Date: Thu, 21 Jul 1994 10:49:42 +0100 (BST)
- In-Reply-To: <Pine.3.87.9407210138.A781-0100000@grad> from "Timothy Miller" at Jul 21, 94 01:46:38 am
- X-Tremely: Sexy
- Precedence: bulk
-
- > We're saying to stop using dialogs.
- >
- I don't think that's what's being said. Stop using form_do() perhaps, but
- not stop using dialogs. Just use them differently.
-
- > Hey, this is the way GEM is. If we're going to require dialogs to be in
- > windows, then it should made part of the operating system.
- >
- Well, I'm an X developer when I'm not working on the atari, so I can't speak
- for Macs or PCs, but putting your forms in windows is not something the OS
- does for you under any of the X toolkits, its up to the programmer. For that
- matter, amodal form handling is not part of X per se, its provided by the
- various toolkits. If you were to program at the basic X level then it would
- be quite possible to have multiple event loops in different parts of your
- code, and produce a modal application. And anyway, see below...
-
- > functionality of the OS. MultiTOS and Geneva should put dialogs for apps
- > automatically into windows and handle them accordingly.
- >
- And how do you see this working? The applications need to be changed as well,
- or putting the forms in windows is going to do nothing more than giving them
- a border. If you've got a form that can stay up whilst the rest of the program
- is running then you're program has got to be able to accept events from it
- at any time. There's no way the OS could do this for you.
-
- > Every new program that supports that section of the GEM-List standards
- > should put dialogs in windows. Fine. Every program that wants to
- > properly support multuitasking, definately.
- >
- In the end people will use the programs they like irrespective of wether or
- not they match our standards.
-
- > But then you still have the problem of every program containing extra
- > code for handling dialogs in windows, and each program having a different
- > handler from a different library developer. There will be a lack of
- > consistency and a lot of wasted space.
- >
- Which is why I'm thinking in terms of a shared library option for my toolkit.
- At least that way all apps that use my toolkit will only require one instance
- of the library. As for consistency, isn't that what this list is here for?
-
- > 5k DA that's intended to make some setting and then quit certainly
- > shouldn't be required to puts its dialog in a window. You won't have the
- > dialog open long enough!
- Well no, it shouldn't be required, but its still just as desirable that it
- should. What if you need to check something elsewhere before making that
- setting?
-
- > And then to make standards on something as open-ended and unexplored as
- > amodal dialogs is not reasonable.
- I sort of agree on this, however I don't think amodal dialogs are unexplored.
- They've existed on other platforms for a long time, and standards have been
- set on those platforms - lets steal some ideas
-
-
- > Let's let a few developers
- > take a crack at it, using their own ideas and see what people really use
- > and want.
- Wether we like it or not, this is what is going to happen.
-
- > Can someone tell me how to set up menu_popup's?
-
- Wouldn't you be better asking this in comp.sys.atari.st.tech?
-
- Kev
-
- --
- Kevin O'Donovan
- abaddon@nasoftwr.demon.co.uk
- kebab@cix.compulink.co.uk
-
- Earth shutting down in five minutes--please save all files and log out
-
-